-
Notifications
You must be signed in to change notification settings - Fork 399
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix: Use Patch instead of Update to add/remove finalizers #1801
base: master
Are you sure you want to change the base?
Conversation
172cf54
to
1fa382c
Compare
controllers/controller_shared.go
Outdated
// Remove finalizer through a MergePatch | ||
// Avoids updating the entire object and only changes the finalizers | ||
func removeFinalizer(ctx context.Context, cl client.Client, cr client.Object) error { | ||
patch := []byte(`{"metadata":{"finalizers":null}}`) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Although it's nice that you can fix the drift with these changes, I would disagree with the way how patches are formed. - Kubernetes objects may have multiple finalizers, whereas, in this PR, there is an assumption that there will always be a single finalizer (owned by the grafana-operator). - Some users might have their own finalizers (think of custom operators).
Since controllerutil
has two functions that safely add (AddFinalizer
) / remove (RemoveFinalizer
) a particular finalizer, you can, for instance, have them modify finalizers in a CR object and then prepare a patch by copying value from metadata.finalizers
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, I'll try and whip up a solution that safely patches the finalizers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I ended up almost copying the controllerUtil.RemoveFinalizer
implementation for removing a finalizer as it worked quite well already.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if we should copy code from anywhere. Do you see any benefits compared to direct calls to their library? - Like it was mentioned in my previous comment, I thought of rather calling controllerutil.AddFinalizer
/ controllerutil.RemoveFinalizer
and then copying finalizers
field from the result. - It's pretty straightforward, we don't have to maintain code of the underlying functions, and it doesn't create licensing complexity (I think you have to mention authors when copying Apache2 code).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I partially misunderstood your previous message.
This is iteration aligns with your suggestions!
cdde804
to
b778a52
Compare
Once this is merged, I will likely add finalizers to |
b778a52
to
a99dc26
Compare
Managed to solve the perpetual drift noted in #1776 that is rooted in us applying finalizers and updating unintended fields on CRs.
I first attempted to use
JSONPatch
, but I could not for the life of me get the libraries to comply, despite handcrafting a working patches with kubectl.MergePatch
worked immediately.Currently, the implementation is hardcoded to only support arrays of one finalizer. More work can be done to make this support multiple if the need ever arises.